Add ICM40609D IMU driver - #11765

Description

Adding ACC_ICM40609D before ACC_FAKE shifts the numeric value of ACC_FAKE, so configs saved with
acc_hardware=FAKE will deserialize as ACC_ICM40609D after upgrade and attempt to initialize the
wrong sensor driver.

Code

src/main/sensors/acceleration.h[R47-50]

  ACC_ICM45686,
+    ACC_ICM40609D,
  ACC_FAKE,
  ACC_MAX = ACC_FAKE

Evidence

The PR changes the enum ordering and YAML table ordering, and the accelerometer hardware selection
is read from persisted configuration and used directly during init; PG records store raw bytes, so
changing enum numeric values changes how old configs are interpreted.

src/main/sensors/acceleration.h[34-51]
src/main/fc/settings.yaml[1-6]
src/main/sensors/acceleration.c[304-317]
src/main/config/config_eeprom.c[56-72]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ACC_ICM40609D` was inserted before `ACC_FAKE`, which changes the implicit numeric value of `ACC_FAKE`. Because `accelerometerConfig()->acc_hardware` is persisted as a raw PG value, existing saved configs using `ACC_FAKE` will be misinterpreted as `ACC_ICM40609D` after flashing this firmware, causing incorrect sensor init.
### Issue Context
- `accelerometerConfig` is a persisted PG and `acc_hardware` is used directly for detection.
- The YAML table is order-synced with the enum, so the numeric index change is real.
### Fix Focus Areas
- src/main/sensors/acceleration.h[34-51]
- src/main/sensors/acceleration.c[90-101]
- src/main/fc/settings.yaml[1-6]
- src/main/config/config_eeprom.c[56-72]
### Suggested fix approach
- Implement a backward-compatibility migration:
- Bump the `accelerometerConfig` PG version.
- On load of older versions, remap the old numeric value that previously meant `ACC_FAKE` to the new `ACC_FAKE` value.
- Alternatively (less preferred if many enums rely on ordering), assign explicit stable numeric values for the enum members and update any loops/range checks accordingly, ensuring `ACC_MAX` reflects the true maximum.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Adding ACC_ICM40609D before ACC_FAKE shifts the numeric value of ACC_FAKE, so configs saved with
acc_hardware=FAKE will deserialize as ACC_ICM40609D after upgrade and attempt to initialize the
wrong sensor driver.

Code

src/main/sensors/acceleration.h[R47-50]

   ACC_ICM45686,
+    ACC_ICM40609D,
   ACC_FAKE,
   ACC_MAX = ACC_FAKE

Evidence

The PR changes the enum ordering and YAML table ordering, and the accelerometer hardware selection
is read from persisted configuration and used directly during init; PG records store raw bytes, so
changing enum numeric values changes how old configs are interpreted.

src/main/sensors/acceleration.h[34-51]
src/main/fc/settings.yaml[1-6]
src/main/sensors/acceleration.c[304-317]
src/main/config/config_eeprom.c[56-72]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ACC_ICM40609D` was inserted before `ACC_FAKE`, which changes the implicit numeric value of `ACC_FAKE`. Because `accelerometerConfig()->acc_hardware` is persisted as a raw PG value, existing saved configs using `ACC_FAKE` will be misinterpreted as `ACC_ICM40609D` after flashing this firmware, causing incorrect sensor init.
### Issue Context
- `accelerometerConfig` is a persisted PG and `acc_hardware` is used directly for detection.
- The YAML table is order-synced with the enum, so the numeric index change is real.
### Fix Focus Areas
- src/main/sensors/acceleration.h[34-51]
- src/main/sensors/acceleration.c[90-101]
- src/main/fc/settings.yaml[1-6]
- src/main/config/config_eeprom.c[56-72]
### Suggested fix approach
- Implement a backward-compatibility migration:
- Bump the `accelerometerConfig` PG version.
- On load of older versions, remap the old numeric value that previously meant `ACC_FAKE` to the new `ACC_FAKE` value.
- Alternatively (less preferred if many enums rely on ordering), assign explicit stable numeric values for the enum members and update any loops/range checks accordingly, ensuring `ACC_MAX` reflects the true maximum.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

icm40609dDeviceDetect() uses a uint8_t post-decrement do/while which performs 6 WHO_AM_I reads for
attemptsRemaining=5, adding an extra 150ms delay and making retry behavior misleading.

Code

src/main/drivers/accgyro/accgyro_icm40609d.c[R192-195]

+        if (tmp == ICM40609D_WHO_AM_I_CONST) {
+            return true;
+        }
+    } while (attemptsRemaining--);

Evidence

The loop condition uses post-decrement on an unsigned counter in a do/while, which evaluates the old
value and therefore executes once when the counter reaches 0 (6 total iterations for an initial
value of 5).

src/main/drivers/accgyro/accgyro_icm40609d.c[174-198]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The retry loop in `icm40609dDeviceDetect()` runs one extra time due to `do { ... } while (attemptsRemaining--);` with an unsigned counter. This adds an extra delay on failed detection and obscures intent.
### Issue Context
This does not cause an infinite loop, but it *does* perform 6 attempts when initialized to 5.
### Fix Focus Areas
- src/main/drivers/accgyro/accgyro_icm40609d.c[174-198]
### Suggested fix approach
Replace with an explicit bounded loop, e.g.:

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

icm40609dDeviceDetect() uses a uint8_t post-decrement do/while which performs 6 WHO_AM_I reads for
attemptsRemaining=5, adding an extra 150ms delay and making retry behavior misleading.

Code

src/main/drivers/accgyro/accgyro_icm40609d.c[R192-195]

+        if (tmp == ICM40609D_WHO_AM_I_CONST) {
+            return true;
+        }
+    } while (attemptsRemaining--);

Evidence

The loop condition uses post-decrement on an unsigned counter in a do/while, which evaluates the old
value and therefore executes once when the counter reaches 0 (6 total iterations for an initial
value of 5).

src/main/drivers/accgyro/accgyro_icm40609d.c[174-198]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The retry loop in `icm40609dDeviceDetect()` runs one extra time due to `do { ... } while (attemptsRemaining--);` with an unsigned counter. This adds an extra delay on failed detection and obscures intent.
### Issue Context
This does not cause an infinite loop, but it *does* perform 6 attempts when initialized to 5.
### Fix Focus Areas
- src/main/drivers/accgyro/accgyro_icm40609d.c[174-198]
### Suggested fix approach
Replace with an explicit bounded loop, e.g.:

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

💡 Did you know, you can route each action level your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

• Add new ICM40609D accel/gyro driver with datasheet-verified init, scaling, and reset.
• Integrate ICM40609D into gyro/acc autodetect, enums, CLI names, and settings tables.
• Select ODR from requested gyro sample interval to avoid silently capping loop rate.

graph TD
  A["FC config (settings.yaml/cli.c)"] --> B["Sensor enums (gyro.h/acceleration.h)"] --> C["Autodetect dispatch (gyro.c/acceleration.c)"] --> D["ICM40609D driver"] --> E["Bus layer"] --> F["ICM-40609-D chip"]
  G["Build sources (CMakeLists.txt)"] --> D

Loading

The following are alternative approaches to this PR:

1. Parameterize ICM42605 driver for ICM40609D variant

• ➕ Reduces duplicated init/read logic across similar TDK/Invensense IMUs
• ➕ Centralizes common ODR/range/filter handling and bus reset patterns
• ➖ Risk of over-generalizing two chips with subtle register-map differences
• ➖ Harder to review/validate initially than a dedicated datasheet-driven driver

2. Introduce a shared 'ICM4x6xx' common layer plus per-chip tables

• ➕ Keeps per-chip differences explicit (tables/constants) while sharing mechanics
• ➕ Easier to add future related parts without copy/paste
• ➖ Higher upfront refactor cost and churn across existing drivers
• ➖ May be premature until there are multiple drivers needing the abstraction

Recommendation: The dedicated driver approach in this PR is appropriate because the ICM40609D has verified differences (reset register, accel FS encoding, missing INT_CONFIG1/ASYNC_RESET) that are easy to validate in a standalone implementation. Consider a follow-up refactor to extract common ICM4xxx bus/init helpers only after this driver is proven on real hardware and additional similar chips justify the abstraction.

Enhancement (8) +304 / -0

accgyro_icm40609d.cImplement ICM40609D accel/gyro driver with ODR selection +256/-0

Implement ICM40609D accel/gyro driver with ODR selection

• Adds a new TDK ICM-40609-D driver implementing device detect/reset via WHO_AM_I, low-noise power mode init, low-latency UI filter config, accel/gyro reads, and temperature conversion. Selects ODR based on requested gyro sample interval using a rate table (mirroring ICM42605) and documents omission of the ICM42605 ASYNC_RESET step because INT_CONFIG1 is absent on this chip.

src/main/drivers/accgyro/accgyro_icm40609d.c

accgyro_icm40609d.hExpose ICM40609D detect entrypoints +21/-0

Expose ICM40609D detect entrypoints

• Declares icm40609dAccDetect() and icm40609dGyroDetect() for use by the sensor autodetect dispatchers.

src/main/drivers/accgyro/accgyro_icm40609d.h

accgyro_mpu.hAdd centralized ICM40609D WHO_AM_I constant +1/-0

Add centralized ICM40609D WHO_AM_I constant

• Defines ICM40609D_WHO_AM_I_CONST (0x3B) alongside other IMU identity constants for consistent detect logic.

src/main/drivers/accgyro/accgyro_mpu.h

bus.hAdd DEVHW_ICM40609D bus hardware id +1/-0

Add DEVHW_ICM40609D bus hardware id

• Introduces DEVHW_ICM40609D to allow bus device registration and opening of ICM40609D instances distinctly from other IMUs.

src/main/drivers/bus.h

acceleration.cWire ICM40609D accel detect into autodetect path +13/-0

Wire ICM40609D accel detect into autodetect path

• Includes the new driver header and adds an ACC_ICM40609D case to accDetect(), supporting both explicit selection and autodetect fallthrough behavior.

src/main/sensors/acceleration.c

acceleration.hAdd ACC_ICM40609D enum value +1/-0

Add ACC_ICM40609D enum value

• Introduces ACC_ICM40609D to the accelerationSensor_e enumeration for configuration and dispatch integration.

src/main/sensors/acceleration.h

gyro.cWire ICM40609D gyro detect into autodetect path +10/-0

Wire ICM40609D gyro detect into autodetect path

• Includes the new driver header and adds a GYRO_ICM40609D case to gyroDetect(), allowing the new driver to be selected via autodetect when enabled.

src/main/sensors/gyro.c

gyro.hAdd GYRO_ICM40609D enum value +1/-0

Add GYRO_ICM40609D enum value

• Introduces GYRO_ICM40609D to the gyroSensor_e enumeration to support CLI/config selection and autodetect dispatch.

src/main/sensors/gyro.h

Other (3) +4 / -2

CMakeLists.txtAdd ICM40609D driver sources to build +2/-0

Add ICM40609D driver sources to build

• Registers the new accgyro_icm40609d.c/.h files in the common source list so they are compiled when enabled by target configuration.

src/main/CMakeLists.txt

cli.cExpose ICM40609D in CLI gyro name table +1/-1

Expose ICM40609D in CLI gyro name table

• Adds the ICM40609D string to gyroNames[] to keep CLI-visible names synchronized with the gyroSensor_e enum order.

src/main/fc/cli.c

settings.yamlAdd ICM40609D to acc_hardware settings table +1/-1

Add ICM40609D to acc_hardware settings table

• Extends the acc_hardware values list with ICM40609D, maintaining ordering alignment with accelerationSensor_e.

src/main/fc/settings.yaml

Description

Adding ACC_ICM40609D before ACC_FAKE shifts the numeric value of ACC_FAKE, so configs saved with
acc_hardware=FAKE will deserialize as ACC_ICM40609D after upgrade and attempt to initialize the
wrong sensor driver.

Code

src/main/sensors/acceleration.h[R47-50]

    ACC_ICM45686,
+    ACC_ICM40609D,
    ACC_FAKE,
    ACC_MAX = ACC_FAKE

Evidence

The PR changes the enum ordering and YAML table ordering, and the accelerometer hardware selection
is read from persisted configuration and used directly during init; PG records store raw bytes, so
changing enum numeric values changes how old configs are interpreted.

src/main/sensors/acceleration.h[34-51]
src/main/fc/settings.yaml[1-6]
src/main/sensors/acceleration.c[304-317]
src/main/config/config_eeprom.c[56-72]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ACC_ICM40609D` was inserted before `ACC_FAKE`, which changes the implicit numeric value of `ACC_FAKE`. Because `accelerometerConfig()->acc_hardware` is persisted as a raw PG value, existing saved configs using `ACC_FAKE` will be misinterpreted as `ACC_ICM40609D` after flashing this firmware, causing incorrect sensor init.

### Issue Context
- `accelerometerConfig` is a persisted PG and `acc_hardware` is used directly for detection.
- The YAML table is order-synced with the enum, so the numeric index change is real.

### Fix Focus Areas
- src/main/sensors/acceleration.h[34-51]
- src/main/sensors/acceleration.c[90-101]
- src/main/fc/settings.yaml[1-6]
- src/main/config/config_eeprom.c[56-72]

### Suggested fix approach
- Implement a backward-compatibility migration:
 - Bump the `accelerometerConfig` PG version.
 - On load of older versions, remap the old numeric value that previously meant `ACC_FAKE` to the new `ACC_FAKE` value.
- Alternatively (less preferred if many enums rely on ordering), assign explicit stable numeric values for the enum members and update any loops/range checks accordingly, ensuring `ACC_MAX` reflects the true maximum.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

icm40609dDeviceDetect() uses a uint8_t post-decrement do/while which performs 6 WHO_AM_I reads for
attemptsRemaining=5, adding an extra 150ms delay and making retry behavior misleading.

Code

src/main/drivers/accgyro/accgyro_icm40609d.c[R192-195]

+        if (tmp == ICM40609D_WHO_AM_I_CONST) {
+            return true;
+        }
+    } while (attemptsRemaining--);

Evidence

The loop condition uses post-decrement on an unsigned counter in a do/while, which evaluates the old
value and therefore executes once when the counter reaches 0 (6 total iterations for an initial
value of 5).

src/main/drivers/accgyro/accgyro_icm40609d.c[174-198]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The retry loop in `icm40609dDeviceDetect()` runs one extra time due to `do { ... } while (attemptsRemaining--);` with an unsigned counter. This adds an extra delay on failed detection and obscures intent.

### Issue Context
This does not cause an infinite loop, but it *does* perform 6 attempts when initialized to 5.

### Fix Focus Areas
- src/main/drivers/accgyro/accgyro_icm40609d.c[174-198]

### Suggested fix approach
Replace with an explicit bounded loop, e.g.:
```c
for (uint8_t i = 0; i < 5; i++) {
   delay(150);
   if (busRead(dev, MPU_RA_WHO_AM_I, &tmp) && tmp == ICM40609D_WHO_AM_I_CONST) {
       return true;
   }
}
return false;
```
(or keep the existing structure but use `while (attemptsRemaining-- > 0)` and ensure the intended attempt count).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools